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ABSTRACT 


The  purpose  of  this  treatise  is  to  contribute  to  the  Improvement  of 
ship  acquisition  in 'the  U.S.  Mavy  by  presenting  a new  look  at  the 
early  stages  of  ship  development  and  suggesting  that  certain  management 
tools  be  applied.  The  thrust  of  the  recommendation  for  management 
improvement  Is  the  attainment  of  a positive  and  orderly  Pre-Acquisition 
Phase  with  the  central  theme  of  Integration.  The  lack  of  a coordinated 
effort  to  systematically  examine  operational  needs  and  to  assimilate  the 
results  of  studies  and  ongoing  developments  creates  a situation  in  which 
needs,  gaps  and/or  shortfalls  are  not  identified  until  a ship  conceptual 
design  begins.  The  result  is  that  in  many  cases  the  products  of  develop- 
ment programs  cannot  meet  the  production  schedule  of  the  ship  which 
prompted  the  development. 

N 


For  approximately  two  years  the  Naval  Sea  Systems  Command  has  been 
involved  in  the  Notional  Ship  Development  (NSD)  program;  that  is,  a 
routine  system  to  identify  the  mission  essential  subsystems  of  planned 
advanced  ship  systems  prior  to  the  conceptual  design  phase.  This  system 
aids  in  the  establishment  of  a Needs  Base  Line  (NBL)  which  sets 
the  stage  to  begin  the  conceptual  design  phase  which  terminates  with  a 
Conceptual  Base  Line  (CBL ) . A computerized  NBL  data  bank  has  been 
established  at  the  David  W.  Taylor  Naval  Ship  Research  and  Development 
Center.  The  principal  elements  in  the  data  bank  are  a catalogue  of 
operational  needs  and  pertinent  information  concerning  RAD  projects. 

Both  needs  and  projects  are  matched  with  applicable  ship/craft  and  the 
integration  agent  is  in  the  form  of  OPNAV  approved  Sub-Operational 
Capabilities  (SOC).  The  new  look  stresses  using  existing  tools  such  as 
the  NAVSEA  Ship  Work  Breakdown  Structure  (SWBS)  and  OPNAV  SOCs  and 
improvising  improvements  within  the  present  system. 


The  Notional  Ship  Development  program  is  not  presented  as  the 
solution  to  all  ship  acquisition  problems,  but  is  aimed  at  improving  the 
pre-acquisition  phase.  However,  the  success  of  each  function  of  acquisition 
depends  In  great  part  on  how  well  the  preceding  function  was  accomplished. 

It  Is  submitted  that  each  player  in  the  acquisition  process  can  gain  by 
supporting  and  using  the  program. 

There  are  many  problems  yet  to  be  solved  and  much  data  to  be  collected 
and  analyzed.  The  program  is  considered  a dynamic,  evolving  management 
tool  which  has  something  to  offer  for  all  and  the  potential  to  greatly 
improve  the  ship  acquisition  process.  To  be  useful  it  must  be  used;  to 
be  used  it  must  be  accepted;  to  be  accepted  it  must  be  understood,  if 
not  in  whole,  certainly  in  specific  areas  of  application. 
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A.  INTRODUCTION 
1.  PURPOSE 

The  effort  described  in  this  paper  has  but  one  goal , to 
contribute  to  the  improvement  of  ship  acquisition  in  the  i).S.  Navy. 

Since  the  primary  mission  of  NAVSEA  is  the  acquisition  of  ships  and 
craft,  with  appropriate  combat  systems,  for  the  operation  forces  of  the 
Navy,  this  paper  is  written  from  a NAVSEA  point  of  view  and  dwells 
primarily  on  aspects  of  the  early  phases  of  decisions  for  ship  acquisition. 
To  establish  a common  base  for  departure,  a simplified  summary  of  the 
what,  why  and  how  of  ship  acquisition  is  presented  by  the  following 
hypothesis: 


A.  INSTALLED  SHIPBORNE  EQUIPMENT/SYSTEMS,  which 

B.  PROVIDE  OPERATIONAL  CAPABILITIES,  at 

C.  CURRENT  PERFORMANCE  LEVELS,  have 
0.  OBSERVED  DEFICIENCIES,  or 
E.  POTENTIAL  INADEQUACIES,  which  require 


) 


) 


F.  RESOURCE  ALLOCATION,  or 

G.  ENGINEERING  ADAPTATION,  or 

H.  DEVELOPMENT,  to 


} 


' STARTING 
POINT 

» 

' OPERATIONAL 
NEEDS 

» 

f RESPONSIVE 


SOLUTIONS 


I.  REPLACE,  or 

J.  IMPROVE  CURRENT  OPTIONS  OF  SUBSYSTEMS,  for 

K.  NEW  CONSTRUCTION,  or 

L.  MODERNIZATION  OF  NAVY  SHIPS 


EMS 

} 


} 


MODE  OF 


APPLICATION 


In  the  past  needs  have  not  been  catalogued  so  that  they  can  be 
readily  identified  and  compared  with  both  ongoing  developments  and 
Inventory  equipments  to  optimize  resource  allocation  or  to  reveal  gaps 
or  shortfalls.  As  a result,  Pre-Acquisition  planning  is  not  as  timely 
nor  as  selective  as  it  should  be.  The  relevance  of  needs  to  RAD  projects 
and  to  Inventory  equipments  Is  not  comprehensively  addressed  due  to 
inattention  of  management  to  valuable  information. 


I 


1 


At  present  the  early  development  efforts  involving  the  ship 
are  conducted  separately  from  the  development  of  subsystems.  An  earlier 
Integration  of  both  development  efforts  could  decrease  acquisition  time 
and  could  increase  efficiency  of  design.  Not  only  is  earlier  technical 
integration  important,  but  also,  an  earlier  integration  of  development 
time  schedules  could  greatly  enhance  ship  construction  planninq. 

There  is  currently  no  systematic  approach  to  correlate  the 
results  of  studies  aimed  at  formulating  a coordinated  NAVSEA  development 
program.  Many  RAD  managers  along  with  their  technical  consultants  in 
other  Directorates,  Laboratories,  and  Industry,  are  individually  studying 
the  need  for  the  constraints  on,  or  the  application  of,  their  particular 
fields  of  Interest.  These  valid  explorations  eventually  influence  the 
direction  of  RAD  planning.  Their  impact  on  other  fields  of  interest  are 
taken  into  account  to  the  degree  that  the  study  director  understands  or 
desires.  The  affected  areas  may  have  no  knowledge  of  the  potential 
Impact  unless  an  objective  management  control  system  is  set  in  motion. 

Another  serious  void  in  Pre-Acquisition  planning  is  the  absence 
of  an  organized  needs/requirements  index  with  accompanying  performance 
data  required  to  fulfill  the  need.  The  threats  posed  by  anticipated 
enemies  of  the  U.S.  create  technical  needs  for  combat  ship  systems  to 
neutralize  or  destroy  those  threats.  CNO  examines  the  needs  and  (eventually) 
establishes  Operational  Requirements  (OR).  These  OR  constitute  the 
prime  driving  force  for  implementation  of  developments,  but  all  known 
?ds  should  be  considered  earlier  and  addressed  in  the  development 
punning  process. 

New  developments  are  Influenced  not  only  by  the  requirements 
"pull"  but  also  by  the  technology  "push".  New  technology  is  continuously 
emerging  and  existing  technology  is  constantly  changing.  Developments 
which  evolve  Independently  of  requirements  pull  must  either  satisfy  an 
existing  need  or  create  a situation  in  which  new  needs  emerge.  Allocation 
of  RAD  resources  traditionally  has  reflected,  to  some  degree,  the  success 
of  various  program  advocates  in  "selling"  the  program  in  which  they  are 
Interested.  This  Is  not  to  say  that  the  programs  being  supported  do  not 
address  a need,  but  rather  to  point  out  that  there  may  be  proposals 
which  do  address  critical  needs  but  are  not  being  supported  because 
they  lack  a dynamic  advocate. 

The  authors  intend  to  discuss  the  tools  for  the  management  of 
a positive,  well  planned  Pre-Acqui si tion  Phase  with  a central  theme. 
Integration  of  elements  A through  L of  the  hypothesis. 

Display  1 contains  a summary  of  events  associated  with  ship 
development  and  presents  an  outline  of  the  overlap  of  Pre-Acquisition 
(as  defined  by  the  authors)  with  the  Conceptual  Design  and  Preliminary 
Design  Phases1.  "Acquisition"  (as  defined  by  the  authors)  commences,, 
when  an  alternative  is  selected  by  CNO  from  the  Development  Proposal^ 

(DP)  and  the  funding  of  that  option  is  approved  by  OSD  and  Congress. 


Although  the  Pre-Acqui si tion  Phase  encompasses  those  activities 
preceding  the  response  to  funding  requests  it  is  In  the  shaded  area  of 
Display  1 that  the  authors  will  concentrate  their  approach  to  the  theme 
of  Pre-Acquisition  Integration.  The  shaded  portion  depicts  no  events  at 
the  SYSCOM  level  because,  although  there  are  planning  actions  taking 
place,  they  are  not  consistent,  routine,  or  coordinated. 


NAVSEA  is  continuously  enqaged  in  a dialogue  with  OPNAV  both 
prior  to  and  after  the  issuance  of  the  Operational  Requirement  (OR). 

NAVSEA  plays^an  important  role  in  the  formulation  of  the  Top  Level 
Requirements'5  (TLR),  the  Tactical  Operational  Requirements  and  the  base 
lines  associated  with  the  ship  desiqn  process.  The  ability  to  provide 
this  kind  of  support  relies  upon  those  very  early  activities  not  identified 
on  charts  such  as  Display  1 because  their  contributions  are  not  recognized 
nor  appreciated;  e.g.,  analysis  of  subsystem  needs  independent  of  ship 
devel opment. 


Display  1 begins  with  appraisals  of  threats  and  identification 
of  needs  by  OPNAV.  Parallel  to  this,  preparation  must  be  made  in  NAVSEA 
for  potential  technology  solutions  to  operational  problems.  In  order 
for  SYSCOM  RAD  (ship  design)  managers  to  devise  (ship)  Development 
Proposals  during  the  Conceptual  Design  Phase,  they  must  possess  sub- 
stantial knowledge  of  operational  needs  prior  to  receiving  an  Operational 
Requirement  for  a ship. 


The  OR  appears  as  the  signal  to  take  advantage  of  the  analyses 
of  alternatives  and  developments  which  have  taken  place  (it  is  time  to 
make  a decision  on  the  configuration  of  a new  ship). 


The  alternative  ship  systems  listed  in  the  Development  Proposal 
(DP)  must  be  responsive  to  the  mission  expectations  in  the  OR,  and  the 
subsystems  defining  alternative  ship  systems  must  already  be  developed 
or  near  completion.  Obviously  RAO  proqram  managers  must  have  conducted 
earlier  analyses  in  their  assigned  areas  to  support  proposed  development 
programs. 


The  process  of  Ship  Pre-Acqui si tion  involves  a set  of  sequential 
and  parallel  activi ties,  each  of  which  reouires  resources  and  is  a sub- 
process. The  successes  of  these  activities  depend  upon  the  adequacy  of 
fundi  no  and  the  capabilities  of  participants. 


Each  sub-process  activity  has  a set  of  tool s and  products 
which  ideally  is  desioned  to  fulfill  objectives  efficiently  and  to 
provide  information  effectively  to  other  sub-processes. 


The  total  process  is  not  under  the  control  of  one  organization 
at  the  decision  level,  and  therefore  is  not  expected  to  be  thorounhly 
coordinated.  An  independent  view  of  how  the  pieces  fit  together  has  led 
to  the  observation  of  opportunities  for  improvement  to  be  discussed. 
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The  foregoing  hypothesis  in  an  interpretation  of  a practical 
situation  to  manage  the  process  more  efficiently.  The  primary  aspects 
of  attempting  this  are  predicated  on  (a)  knowing  who  the  participants 
are,  (b)  understanding  their  roles  and  how  they  are  implemented,  (c) 
determining  what' would  be  worthwhile  to  change,  and  (d)  convincing  the 
participants  to  utilize  the  changes. 

This  paper  does  not  advocate  re-inventing  the  wheel.  Rather, 
the  approach  of  the  authors  is  to  take  a new  look  at  the  early  stages  of 
ship  development  and  to  advocate  improvements  within  the  present  system. 

The  success  of  each  function  of  acauisition  depends  in  great  part  on  how 
well  the  preceding  function  was  accomplished.  Weak  initial  planning 
results  in  gaps  and/or  shortfalls  in  development  programs.  Development 
programs  which  do  not  satisfactorily  address  operational  needs  result  in 
ship  and  weapon  system  designs  based  on  alternatives  which  do  not 
represent  the  best  selections  and  are  therefore  very  costly. 

Pre-Acqui sition  functions  performed  before  the  OR  is  issued  are 
equally  the  responsibilities  of  OPNAV,  NAVSEA  and  others.  Each  must 
participate  in  those  activities  which  ensure  effective  lonq  range 
planning  for  development  and  design.  If  NAVSEA  were  to  react  only  by 
planning  development  after  an  OR  is  received,  the  acquisition  process 
would  take  several  more  years  than  it  takes  now.  The  lack  of  a coordinated 
effort  to  examine  needs  systematically  and  to  assimilate  the  results  of 
studies  and  ongoing  development  efforts  is  reflected  in  the  current 
problems  in  Pre-Acquisition  planning  efforts. 

2.  BACKGROUND 

In  order  to  set  the  stage  for  an  approach  to  improve  ship 
acquisition  by  defining  an  orderly  comprehensive  Pre-Acgui si tion  Phase, 
it  is  appropriate  to  review  current  practices  and  a brief  history  of  the 
evolution  of  the  effort.  Several  years  ago  a planning  tool  was  developed 
which  organized  R&D  projects  with  their  applicable  ship  systems  into 
matrices.  These  matrices  were  published  in  the  Advanced  Ship  Systems 
Development  Planning  Manual^  and  included  descriptions  of  ships  and  R&D 
projects  with  pertinent  data  and  major  milestones  of  ship  development. 

The  manual  was  designed  to  aid  ship  development  managers  ascertain 
"advanced  alternatives"  in  subsystem  selection  However,  it  became 
apparent  that,  because  of  time  constraints,  the  ship  development  manager 
could  choose  only  from  "off  the  shelf"  subsystems  and  equipments.  The 
Ship  Planning  Manual  also  brought  to  liqht  that  there  are  shortfalls  in 
many  areas  which  were  not  being  satisfied  by  development  of  new  subsystems. 

On  the  positive  side,  the  discovery  of  shortfalls  results  in 
the  initiation  of  new  developments.  On  the  negative  side,  development 
time  is  normally  too  long  to  permit  a new  product  to  meet  the  schedule  of 
the  ship  program  which  prompted  the  development.  This  "catch  up"  process 
(see  Display  2)  is  unacceptable  but  can  be  Improved  (a)  by  ensuring  an 
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awareness  by  all  ship  development  participants  of  the  subsystem  developments 
underway  and  those  proposed  and  (b)  by  ensuring  an  awareness  by  all 
subsystem  development  participants  of  the  operational  needs  (and  capability 
performance  levels)  of  developing  ships.  The  Ship  Planning  Manual  was 
designed  to  make  planners  aware  of  all  developments  and  was  periodically 
updated  to  reflect  current  developments  in  both  ships  and  subsystems. 

It  became  more  and  more  o.  .ious  that  ship  and  combat  systems 
acquisition  programs  had  many  managers  making  decisions  concerning  a 
myriad  of  items  and  that  there  was  no  central  source  of  information  from 
which  managers  could  find  a common  departure  point. 

In  view  of  the  deficiencies  just  described  in  the  current  Pre- 
Acquisition  and  early  Acquisition  phases  of  ships  and  combat  systems 
development,  there  is  a definite  need5  for  a positive  planning  tool. 

The  current  relationships  between  groups  of  people  who  deal  with  each 
other  in  the  normal  course  of  Navy  business  are  not  the  targets  for 
improvement  to  be  discussed  here.  Rather,  the  realization  that  discon- 
nected groups  eventually  are  contributing  to  Navy  goals  beyond  the 
purview  of  individual  groups  demands  that  "super"  integration  be  given 
serious  thought.  It  is  recognized  that  interfaces  between  dispersed 
groups  require  continuous  attention.  Hopefully  this  paper  will  be  taken 
as  an  invitation  to  participants  to  become  identified  with  this  effort 
and  to  improve  the  interpretation  of  their  involvement  as  presented. 

The  sampling  of  on-going  "mechanisms"  investigated  thus  far  will  be 
described  only  in-so-far  as  necessary  to  integrate  their  objectives  and 
1 nput/output. 


B.  APPROACH 


1.  THE  NEW  LOOK 

The  preceding  description  of  the  current  pre-acquisition  process 
and  RAD  planning  procedures  points  up  several  areas  in  which  improvements 
are  mandatory.  Starting  in  1974  funds  were  allocated  for  a Notional 
Ship  Development  (NSO)  program.  A "Notional  Ship"  is  a concept  which 
exists  prior  to  conceptual  design  and  ceases  to  exist  when  design  commences. 
It  is  more  specific  than  "generic"  ships  such  as  "submarine"  or  "destroyer" 
but  less  specific  than  a ship  described  by  a TLR.  It  is  described  by  words 
and  numbers  rather  than  by  pictures.  Its  description  relies  on  knowledge 
of  ships  previously  built  in  the  same  generic  category  and  utilizes  the 
same  information  structures  applied  to  previous  ships.  The  anticipated 
mission  and  the  subsystems/performance  levels  describe  the  notion. 

Display  (2)  shows  the  time  relationship  of  NSD  to  acquisition  funding. 

The  NSD  program  defines  an  approach  for  identifyinn  the  mission  essential 
subsystems  of  planned  advanced  ship  systems  prior  to  the  conceptual 
design  phase.  This  NSD  system  provides  the  "New  Look"  approach  which  we 
will  now  discuss.  NSD  aids  in  the  establishment  of  a Needs  Base  Line 
(NBL)  which  sets  the  stage  to  begin  the  conceptual  design  phase  which 
terminates  with  a Conceptual  Base  Line0  (CBL).  The  program  is  intended 
to  provide  back-up  information  and  data  for  conductina  an  improved  pre- 
acquisition process.  It  also  is  intended  to  be  an  easily  updated  system 
so  that  as  the  preacqui sition  process  envoi ves  with  more  modern  and 
sophisticated  techniques,  the  data  contained  in  the  system  and  the 
associated  information  storage  and  retrieval  tools  can  be  modified  to 
maintain  their  usefulness.  Specifically,  the  system  is  being  designed 
to  the  following  objectives: 

o Identify,  index,  and  maintain  current  a data  base  of  all 
the  needs,  deficiencies,  or  shortfalls  of  the  operational 
Navy  forces  to  assist  in  RAD  planning  and  in  study 
evaluations. 

o Provide  and  maintain  current  a data  base  which  can  be 
used  to  accumulate  and  correlate  the  results  of  all 
ongoing  and  proposed  studies  of  new  ship  system  and 
subsystem  developments. 

o Provide  a sound  base  for  establ ishino  priorities  of 
ship  system  or  subsystem  development. 

o Establish  and  document  performance  criteria  for  ship 
ship  systems  and  subsystems. 

o Provide  a continuous  and  systematic  review  and  analysis 
of  the  relationships  between  operational  needs,  inventory 
equipment  capabilities,  and  the  capabilities  of  subsystems 
resulting  from  planned  RAD  efforts. 
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o Contribute  to  the  accompl i shment  of  earlier  technical 
integration  of  new  systems  and  subsystems  into  new 
or  improved  ship  designs. 

o Provide  the  means  to  achieve  ear.ser  integration  of 
ship  system  and  subsystem  development  schedules. 

o Provide  timely  inputs  on  a routine  schedule  as  well 
as  on  an  as-needed  basis  to  the  Fleet  Modernization 
Program  (FMP),  Ship  Acquisition  Managers  (SHAPM),  and 
RSD  Program  Managers  (PM). 

2.  THE  DATA  BASES 

Throughout  the  discussion  one  fact  has  been  continually 
emphasized;  namely,  no  complete  and  organized  listing  of  the  operational 
Navy's  needs  exists,  and  without  such  a listing,  no  coordinated  and 
comprehensive  analyses  can  be  developed  for  use  in  the  various  decision- 
making processes.  The  first  step  toward  implementing  the  Notional  Ship 
Development  concept  was  to  conduct  a thorough  and  systematic  effort  to 
identify  and  to  assemble  in  one  place  all  the  OPNAV-level  documents 
containing  officially  recognized  statements  of  operation  needs,  deficiencies, 
or  shortfalls.  This  collection  effort  identified  some  300  documents, 
summarized  in  Display  3,  to  be  surveyed  for  statements  of  operational 
needs.  Although  only  14  line  items  are  listed  in  the  table,  note  that 
some  are  compilations  of  numerous  other  documents.  The  magnitude  of  the 
number  of  other  documents  collected  substantiated  early  predictions  that 
the  volume  of  data  to  be  accumulated  would  surpass  human  capabilities  to 
maintain  order  and  that  a computerized  data  storage  and  retrieval  system 
would  be  absolutely  necessary.  A characterization  system  is  also  required 
to  describe  each  data  entry  so  that  information  pertinent  to  desired 
objectives  can  be  recognized  by  the  data  retrieval  systems  and  subsequently 
provided  in  a useful  and  organized  format.  As  each  document  was  surveyed 
and  needs  or  deficiences  were  identified,  the  following  data  were  recorded: 

o Document  title,  section  (or  chapter),  and  page  number, 

o Ship  Type  (or  category)  to  which  the  need  applied,  and 

o Priority  assigned  to  the  need  (if  qiven  in  the  document). 

The  statement  of  the  need  was  paraphrased  as  accurately  as  possible  so 
that  the  statement  would  fit  on  a standard  computer  card. 

Each  need  must  be  further  characterized  by  some  system  whereby 
needs  of  similar  nature  can  be  automatically  associated.  The  concept  of 
sub-operational  capabilities'  (SOC)  (see  Display  4)  was  chosen  as  the 
basic  descriptive  element  to  be  used  to  characterize  the  operational 
needs  since  it  is  in  wide  use  within  the  Navy,  including: 
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o MW  IP  11-20,  in  which  the  intendeg  mission  of  each  ship 
type  within  the  Navy  is  defined, 

o FORSTAT,  the  system  for  reporting  operational  f^rce 
status  and  readiness  to  perform  assigned  tasks, 

o ROC,  the  defjnition  of  the  required  operational 

capabilities^  of  each  ship  type  based  on  the  statements 
in  the  approved  characteristics, 

o TLR , Top  Level  Requirements,3  a basic  design  concept 
paper  for  new  or  improved  ship  designs,  and 

o OPTEVFOR"  evaluations  of  new  systems/ subsystems. 

This  structure  fits  very  well  into  the  scheme  since  RAO  programs  as  well 
as  inventory  systems  and  subsystems  can  also  be  associated  by  SOC's. 

Finally,  all  the  extracted  data  relative  to  operational  needs  were 
punched  on  standard  computer  cards  and  stored  on  a magnetic  tape  as  a 
permanent,  but  updatable,  operational  needs  data  file. 

In  an  analogous  manner,  RAD  project  data  were  similarly  assembled, 
characterized,  and  stored  on  magnetic  tape.  Projects  included  all 
NAVSEA  currently  funded  (FY,27)  and  proposed  ( i . e . , Advanced  System 
Concepts (ASC's),  for  POM  j 79,  POM  79,  and  POM  80)  projects,  and  all 
non-NAVSEA  projects  which  pertain  to  shipborne  systems/subsystems/equipments. 
The  type  of  data  prepared  for  each  project  includes: 

o project  title  and  a paraphrased  statement  of  the 
project  objective, 

o SYSCOM  sponsor, 

o element  number  and  project  number  (or  ASC  number), 

o applicable  ship  types,  and 

o applicable  SOC's. 

Several  retrieval  methods  have  been  developed  using  both  the 
needs  data  base  and  the  projects  data  base.  The  aim  of  each  has  been  to 
provide  the  maximum  amount  of  information  in  the  most  concise  and  compre- 
hensible format  possible. 

A subsequent  realization  that  certain  SOC's,  when  organized  in 
groups  of  logically  similar  SOC's,  constitute  a definition  of  an  operational 
"function",  ied  to  a useful  way  to  extract  needs  and  projects.  The  list 
of  functions  resultinq  from  this  analysis  is  shown  in  Display  5.  Since 
both  the  needs  and  projects  are  characterized  as  to  the  applicable  ship 
type,  needs  and  projects  extracted  for  a given  function  and  a given  ship 
type  produce  informative  outputs. 


The  procedure  of  extracting  needs  and  projects  by  function 
and/or  ship  type  works  well,  but  not  for  all  purposes,  because  of  a 
problem  which  arose  durinq  the  initial  characterization  of  needs  and 
project  by  SOC's.  The  analysts  frequently  found  that  some  needs  and 
projects  (particularly  6.2  projects  and  ASC's)  could  not  be  assigned 
obvious  SOC's  because  the  scope  of  either  the  need,  or  the  project,  or 
the  SOC  was  too  detailed  or  too  general.  Therefore,  some  needs  and 
projects  were  assigned  "no  applicable  SOC".  Any  extraction  or  retrieval 
scheme  operating  on  the  basis  of  the  SOC  would  never  extract  these 
items.  The  necessity  for  an  additional  characterization  scheme  became 
obvious  whereby  every  need  and  every  project  can  be  positively  described. 

The  new  system  used  for  characterizing  needs  and  projects  uses 
the  idea  of  "Function/Performance  Areas"  (FPA).  The  FPA. concept  bears  a 
resemblance  to  the  2-digit  Ship  Work  Breakdown  Structure  4 (SWBS)  (see 
display  6)  and  the  two  concepts  could  be  brought  into  agreement  by 
making  some  modifications;  however  no  effort  has  yet  been  directed  toward 
such  a resolution.)  SWBS  provides  a classification  system  whereby  all 
phases  of  a ship  acquisition  or  conversion  project  are  identified 
correlated,  and  categorized  under  a single  functional  index  that  addresses 
requirements,  material , services,  and  components.  The  list  of  FPA  used 
so  far  is  in  Display  7.  This  FPA  list  is  not  all-inclusive,  but  in 
keeping  with  the  program  concept,  it  will  be  developed  over  time. 

It  is  intended  in  the  future  to  obtain  performance  measurement 
data  associated  with  each  need,  project,  and  system/equipment.  This 
would  fit  into  a logical,  acceptable,  pre-known  listing  of  functional 
parameters  to  be  commonly  used  in  communicating  quantitative  data.  The 
fourth  digit  of  the  SWBS,  or  an  alternative  FPA  digit,  might  accommodate 
such  information  now  found  in  the  "performance  sections"  of  TLR  & TLS  5 
or  in  the  "staging  numbers"  of  SECAS.  Both  needs  and  projects  data 
bases  now  have  at  least  one  characterization  scheme  by  which  each  item 
is  extracted  (or  rejected)  through  a positive  action  and  not  by  "default" 
because  the  item  could  not  be  characterized.  A retrieval  model  was 
developed  to  survey  needs  and/or  projects  on  the  basis  of  these  FPA. 

3.  APPLICATION 

The  scope  of  data  required  to  meet  expressed  objectives  of  NSD, 
to  be  responsive  to  observed  problems  in  the  pre-acquisition  phase, 
together  with  an  anticipated  broad  spectrum  of  user  requirements,  dictated 
an  easily  accessible  and  automated  file.  This  section  discusses  potential 
areas  of  application  to  assist: 

o The  operational  user  in  foreseeing  how  advanced  design 
ships'  capabilities  can  be  used  to  satisfy  future 
operational  deficiencies 


o The  acquisition  manager  in  determining  whether  current 
research  and  development  is  properly  oriented  and 
timely  funded  with  respect  to  other  acquisitions 


> 


o The  planner  in  establishing  what  research  and  development 
should  he  proposed  or  re-oriented. 

The  ultimate  specific  application  of  the  products  available  from  the 
data  file  and  the  associated  computer  proqrams  can,  and  probably  will, 
number  as  many  as  the  number  of  users.  What  must  be  emphasized  here  is 
that  the  out-put  obtained  from  the  data  base  is  not  the  ultimate  end 
of  an  analysis.  It  is  intended  only  as  an  aid  to  the  analyst,  e.g.,  to 
guide  him  to  the  location  within  the  various  documents  wherein  official 
Navy  statements/infonnation  may  be  found.  By  following  this  route  he 
will  more  than  likely  locate  additional  backup  material  that  will  advance 
and  enhance  the  ultimate  analysis.  If  the  full  potential  of  this  approach 
to  planning  and  development  is  to  be  realized  and  have  a beneficial 
impact  on  acquisition,  all  potential  areas  of  application  must  be  visible. 
Unique  application  possibl il 1 ties  exist  from  the  OPNAV  level  through  the 
SYSCOM  level  to  the  technologi st/enqineer  level.  Several  possibilities 
of  application  are  discussed  below: 

a.  OPNAV  SPONSOR 


Display  3 lists  source  documents  used  to  identify  the  NBL  needs  and 
their  relation  to  R&D  projects.  Because  it  is  customary  for  the  originators 
of  these  documents  to  permit  or  solicit  review  of  their  drafts,  and  even 
Invite  comments  in  the  published  version,  there  exists  an  opportunity  to 
provide  OPNAV  sponsors  with  the  content  of  the  NBL.  It  can  be  customized 
to  their  mission  In  terms  of  the  SOC  encompassed,  and  it  will  provide 
NAVSEA  opinion  of  the  data  taken  from  the  OPNAV  source,  as  well  as  the 
NAVSEA  perception  of  similar  data  from  other  sources  which  OPNAV  might 
consider  for  inclusion  in  their  update. 

In  particular,  each  mission  sponsor^6  ought  to  be  interested  in 
additional  pertinent  needs,  responsiveness  of  RAO  projects  to  those 
needs,  and  identification  of  equipments/ systems  expected  to  contribute 
to  accomplishment  of  the  mission. 

A spin-off  of  this  ambition  occurs  in  feedback  to  the  basic  instruction 
which  defines  missions  In  terms  of  SOC7  used  in  the  TLR.  The  difficulty 
which  we  experience  in  attempting  to  comprehend  the  requirements  and  to 
explain  the  adequacy  of  the  planned  ship  systems  in  providing  the 
required  capabilities  can  be  reduced  by  clarification  of  the  mission 
definitions.  New  and  revised  SOC  can  be  suqgested  to  better  relate  RAO 
programs  and  TLS  emphases  and  necessary  characterizations. 
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b.  SHAPM/SHIP  DESIGN  MANAGER 


A new  ship  design  effort  currently  includes  preparation  of  a 
Master  Equipment  List  (MEL)  which  initially  may  be  drafted  as  a revision 
of  fcMEL  from  a previous  similar  ship.  It  is  an  early  portion  of  the 
TLS  5 which  provides  some  detail  of  equipments/ systems  which  are  expected 
to  satisfy  the  requirements  of  the  TLR. 

When  the  NBL  data  base  has  been  expanded  to  include  equipment  17 
listings  from  the  Ship  Equipment  Configuration  Accounti no. System  (SECAS)  ' 
file-  a draft  MEL  would  be  available,  organized  by  SWBS,  based  on  the 
ROC  u of  the  TLR.  It  would  describe  the  new  ship  not  only  in  terms  of 
the  options  which  were  selected  for  installation  on  all  current  active 
ships,  with  the  same  SOC  assigned,  but  also  in  terms  of  the  new  options 
and  their  schedules  made  available  by  current  RAD  projects.  It  would 
also  provide  a direct  correlation  of  planned  equipments  in  the  TLS  with 
the  SOC  requirements  of  the  TLR  including  the  redundant  utility  of 
multi-purpose  systems. 

This  repeatable,  comprehensive,  fast  response  print-out  of  the  NBL 
data  provides  the  opportunity  for  earlier  consideration  of  al ternatives. 

It  is  also  planned  to  include  data  for  performance  and  cost  comparisons. 
Additionally,  the  "needs"  which  have  not  been  fulfilled,  that  is,  the 
remaining  inadequacies  observed  but  not  overcome  will  be  visible  to 
indicate  expected  limitations  of  the  new  ship. 

C.  RAO  PROGRAM  MANAGERS 

The  current  RAD  program  has  been  developed,  modified,  restructured, 
and  rejustified  over  the  years.  New  starts  and  stops  occur  each  year. 
Plans  and  accomplishments  are  proclaimed  in  one-time  documentation  and 
in  recurrinq  reports.  Effectiveness  and  efficiency  are  pursued  by  each 
RAD  manager  within  the  constraints  of  the  resources  assigned  or  sought. 
This  management  function  includes  knowing  and  formulating  needs  and 
opportunities  and  being  aware  of  changing  environments  and  the  relevant 
efforts  of  others.  The  group  of  people  immediately  associated  with  an 
individual  Program  Manager  (PM)  reflect  the  scope  of  endeavors  emphasized 
under  his  purview. 

Logic  and  objectivity  demand  that  the  most  important  needs  be 
addressed,  but  lack  of  knowledge  and  politics  limit  the  opportunity  to 
achieve  the  ideal.  The  NBL  data  base  is  desiqned  to  include  those  needs 
and  projects  addressed  by  individual  managers  and  to  organize  them  and 
associate  them  with  other  NAVSEA  business,  namely,  ship  and  subsystem 
acquisitions.  It  is  intended  to  offer  opportunities  to  improve  the  RAD 
programs  by:  (1)  identifying  needs  which  are  not  being  addressed,  but 
are  considered,  by  some  interested  party,  to  be  as  important  as  those 
needs  that  are  receiving  attention  in  the  current  program,  (2)  identifying 
projects/tasks  that  would  overcome  noted  deficiencies  in  the  program, 


and  (3)  associating  all  of  these  with  the  interested  participants  and 
with  the  Individual  equipments/ subsystems  which  would  increase  in  value 
by  having  their  mission  capability  increased. 

d.  FUNCTIONAL  SUBPROGRAM  GROUPS  (FSG) 

1 8 

A concept  called  out  in  the  planning  stages  of  the  RAD  program 
for  the  last  two  years  consists  of  setting  up  about  10  or  15  AO  HOC 
groups,  each  consisting  of  membership  from  all  NAVSF.A  Directorates 
having  an  interest  in  a common  area.  The  objective  of  such  a group  is  to 
make  a comprehensive  review  of  the  assigned  "sub-program"  area,  which 
cuts  across  PM,  Oivision,  and  RAD  categories,  and  to  recommend  to  each 
PM  new  direction  and  emphasis/de-emphasis  needed. 

The  NBL  data  base  has  been  prepared  specifically  for  the  purpose 
of  RAO  planning.  A data  summary  may  be  prepared  similar  to  that  described 
for  a draft  MEL  in  b above,  but  expanded  to  groups  of  ship  types;  e.g., 
all  submarines,  all  combat  surface  ships,  etc.  These  "Development  Needs 
Tables"  would  both  initiate  and  record  the  results  of  in-depth  studies 
of  issues  which  demand  decisions  for  program  direction. 

These  reviews  and  studies  in  effect  formulate  NAVSEA  policy  for  RAD 
and  form  the  bases  for  subsequent  preparation  of  ASC/draft  DR,  DP, 

Program  Plans,  etc.,  and  for  use  at  annual  decision  periods;  e.g.,  POM/ 
Budget/Apportionment.  The  common  basis  for  individual  actions  assures 
coordination  and  a more  united  NAVSEA  image. 

e.  AO  HX  GROUPS 


Over  the  years  our  methods  of  doing  business  have  taken  new  directions, 
our  emphases  in  missions  or  technologies  have  peaked,  and  our  attention 
to  continuing  problems  has  focussed.  Each  decision  to  change  usually 
starts  with  a study  of  the  area  of  concern  which  looks  at  history  as 
well  as  the  occasion  for  change. 

In  the  RAD  business  some  recent  pertinent  examples,  are: 

iq  ?n 

(1)  implementation  of  MENS*  A ZBB£U  concepts  ' 

(2)  emergence  of  Technical  Strategics'^  3 15 

(3)  formulation  of  Top  Level  Requirements'3  and  TLS  3 

(4)  creation  of  "Product  Lines"  at  Labs^ 

(5)  attention  to  Survivability  2 

(6)  preparation  of  Science  A Technology  Objectives^ 

(7)  preparation  of  Proposed  Military  improvements'^ 

(8)  attention  to  Ship/Subsystem  Schedul inq^3 

The  NBL  data  Is  sufficiently  flexible  to  respond  to  demands  for 
unusual  or  comprehensive  listings  of  important  areas  of  concern  to 
assist  the  Initial  efforts  of  a new  group.  Organization  and  early 
collection  of  compilations  of  data  are  extremely  important  when  new 
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direction  is  indicated  and  deadlines  are  Imposed.  Auditable  sources  and 
expressed  priorities  are  valuable  assets  In  such  studies.  Readily 
available  equipment  and  project  data  which  can  be  manipulated  to  focus 


Ion  particular  Interests  provide  an  important  tool  for  AD  Hoc  studies. 

The  additional  data  provided  consists  of  pertinent  needs  statements, 
an  opinion  of  relative  Importance,  the  related  SOC/SWBS  areas,  the  RAD 
projects  and  shipborne  equipments  associated,  and  the  corresponding 
participants  managing,  and  therefore  Interested  In,  the  subject  areas. 

Related  need  statements  from  several  source  documents  offer  expansion  or 
clarification  opportunities. 

f.  ENGINEER/TECHNOLOGIST 

The  engineers  and  technicians  who  assist  RAD  program  managers  In 
the  day-to-day  execution  of  project  development  have  in  many  cases 
different  orientations  and  fields  of  Interest  depending  upon  their 
organizational  situations.  In  fact,  they  may  be  Involved  with  several 
PM' s and  with  several  SYSCOMS.  This  condition  requires  the  engineer  to 
have  a unique  Interest  In  one  or  more  projects  and  knowledge  of  the 
total  team  effort  Involved  In  the  RAD  program  formulation  and/or  application. 

The  structure  of  the  NBL  data  Includes  the  Identification  of  partici- 
pants keyed  to  their  project(s)  of  Interest.  Consequently,  a custom- 
made  summary  can  be  prepared  for  the  benefit  of  each,  reporting  comprehensivel 
In  Individual  areas  of  interest.  The  availability  of  such  outputs 
allows  each  participant  to  take  advantage  of  others'  knowledge  of  equipments 
and  their  operational  capabilities.  A contribution  to  the  planning. 
Implementation,  or  application  of  RAD  projects  can  best  be  appreciated 
If  full  knowledge  of  the  context  (of  needs  being  addressed  or  Ignored, 
and  projects  being  funded  or  deferred)  Is  made  available  to  relate  to 
the  Individual's  knowledge  of  equipments  and  operational  capabilities 
being  affected. 

C.  DISCUSSION 

From  the  preceding  application  It  would  appear  that  the  subject  has 
been  properly  considered  In  terms  of  the  development  of  an  hypothesis 
and  an  approach  to  testing  a methodology.  At  this  point  we  should  turn 
to  a recognition  of  some  of  the  "real  world"  problems  of  application  and 
outline  future  development  requirements.  Once  this  Is  done  we  will  have 
a better  picture  of  the  status  of  the  effort. 

I 

1.  PROBLEMS  OF  APPROACH 

a.  A common  first  step  In  the  solution  of  many  problems  Is 
to  treat  them  as  static.  For  example,  at  this  time  we  look  at  the 
, current  data  base  as  a snapshot  of  needs,  capabilities,  etc.,  and  call 

IS 


it  a baseline.  In  fact  we  have  a changing  baseline.  Needs  change  as  a 
result  of  both  solutions  to  past  problems  and  introductions  of  new  ones. 
If  nothing  else  the  needs  respond  to  changino  threats  over  which  we  have 
no  control . 


The  needs  statements  file  must  be  updated  as  new  documents  and 
new  needs  evolve.  As  more  experience  is  gained  throuqh  sample  runs 
and  actual  user  experience,  errors  in  characterization  as  well  as  incom- 
pletely characterized  needs  must  be  constantly  corrected,  for  this 
approach  to  provide  a viable  baseline  a committment  is  necessary  to 
expend  resources  on  the  maintenance  of  a current  verified  data  file. 

b.  Another  element  in  problem  solving  is  the  establishment 
of  assumptions.  One  assumption  in  the  early  stages  of  development  of 
the  data  bank  was  that  the  sub-operational  capabilities  (SOC)  contained 
in  OPNAVINST'  3501.2  would  provide  a meaningful  interface  for  relating 
needs  to  hardware  systems.  However,  there  are  limitations  in  using 
these  SOC's  because  of  inconsistencies,  omissions,  and  inadequacies.  A 
system  tied  to  SOC's  is  bound  to  inherit  some  of  the  same  problems.  In 
particular,  the  analysts  frequently  find  that  some  needs  cannot  be 
assigned  "obvious"  SOC's  because  the  SOC  level  of  detail  is  too  precise 
or  too  general , or  because  no  SOC  addresses  the  subject.  Therefore, 
some  needs  are  characterized  as  "no  applicable  SOC,"  and  will  not  appear 
in  a SOC  extraction  list  unless  the  SOC  Directive  is  modified  as  suggested 
in  B3(a)  above. 

In  the  meantime  to  alleviate  this  problem,  the  analyst  is 
forced  to  "interpret"  either  the  need  or  the  SOC  (or  both)  in  order  to 
find  a match.  The  "interpretation"  is  an  unacceptable  condition  because 
it  can  and  does  vary  over  broad  limits  among  different  interpreters  as 
well  as  for  the  same  interpreter  over  a period  of  time. 

c.  Another  assumption  problem  carries  over  into  assessment 
area  of  NSD  users.  The  NSD  developer  assumes  that  the  new  approach  to 
planning  will  be  enthusiastically  accepted  by  all  because  of  its  "obvious 
benefits".  Unfortunately  there  is  a problem  of  communication,  which 
affects  both  the  developer  and  the  potential  user.  First,  the  developer 
must  be  aware  of  the  need  to  sell  his  approach.  What's  obvious  to  him 
may  not  be  obvious  to  the  user  or  the  language  he  speaks  may  be  foreign 
to  the  user.  Second,  perhaps  a more  subtle  problem  relates  to  "What's 

in  it  for  me?"  A potential  user  who  has  successfully  cornered  his  share 
of  RAO  dollars  year  in  and  year  out  is  not  going  to  be  enthusiastic 
about  a system  which  might  threaten  his  "rice  bowl".  He  does  not  want 
to  hear  of  any  change.  These  problems  need  both  airing,  as  this  paper 
is  Intended  to  provide,  and  top  management  attention  for  the  best 
interests  of  the  Navy. 


r 


11} 


d.  For  potential  participants  there  is  a serious  considera- 
tion; they  must  be  convinced  that  it's  worthwhile.  Each  individual 
feels  that  his  workload  is  increasing  and  that  time  demands  exceed  the 
time  available.  Yet,  in  the  introduction  of  a system  such  as  this, 
there  is  a need  for  a number  of  people  to  devote  some  of  their  time  to 
review  the  basic  data  and  to  make  the  necessary  judgements  and  evaluations. 
To  obtain  the  necessary  support,  after  the  participant  is  "sold"  on  the 
value  of  the  approach,  the  material  provided  for  the  review  must  be 
prescreened  or  filtered  so  as  to  minimize  the  demand  on  his  time. 

This  latter  point  is  especially  significant  when  one  considers 
the  magnitude  of  the  existing  data  bank,  e.g.,  there  are  presently  over 
1600  needs,  derived  from  approximately  300  source  documents,  related  to 
more  than  780  SOC's,  and  associated  with  one  or  more  types  of  ships 
ranging  from  submarines  to  amphibious  craft  to  aircraft  carriers. 

e.  In  addition,  many  needs  are  directly  related  to  various 
weapons,  sensors,  and  other  systems,  which  have  multiple  functions  and 
applications.  The  preciseness  of  the  definition  of  needs  varies  signi- 
ficantly between  source  documents,  and  with  the  large  number  of  sources 
involved  there  are  bound  to  be  duplications  of  needs.  Furthermore,  in 
many  cases  there  is  a variation  in  the  breadth  of  the  needs  statements. 

If  needs  are  grouped  from  various  sources,  in  addition  to  duplication, 
there  is  also  a problem  in  the  hierarchy  of  needs,  such  as  that  «*«wn 
below  in  a way  which  indicates  the  subordinate  relationships; 

A.  Improved  surface  ship  A$W  capability 

1.  Improved  Detection  and  Classification 

a.  Passive  Towed  Arrays 

b.  Escort  Passive  Capability 

c.  Active  Sonars 

(1)  Active  Sonar  Classification 

(2)  etc 

Each  item  listed  is  included  in  the  current  data  base  as  a separate 
need.  With  such  a tiering  of  needs,  the  basis  for  establishing  priorities, 
for  example,  becomes  difficult  to  define.  Similar  sets  or  families  of 
needs  should  be  identified,  and  a consistent  prioritization  process 
should  be  established  for  treating  hierarchies. 

f.  In  some  organizations,  there  is  little  incentive  to  get 
involved  in  RAD  planning.  In  the  ship  design  community  which  should 
benefit  most  from  this  approach,  RAD  planning  competes  for  time  with 
active  ship  design  programs.  In  some  areas  a person-to-person  relationship 
between  individuals  in  the  organization  and  individual  NAVSEA  program 
sponsors  is  the  only  real  link  in  the  RAD  planning  process.  An  organization 
such  as  NAVSEC,  for  example,  is  neither  staffed  nor  organized  to  effectively 
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support  RAD  planning  as  a corporate  function.  In  a laboratory,  on  the 
other  hand,  where  RAD  Is  of  prime  Importance,  there  are  not  enough 
qualified  Individuals  to  review  operational  needs  and  projects  and  to 
judge  their  applicability  to  newly  developing  ships  on  as  comprehensive 
a basis  as  Is  necessary  for  program  decisions. 

2.  FUTURE  DEVELOPMENT 

As  resources  become  available  for  the  NSD  program  the  development 
of  the  approach  and  Its  applications  are  expected  to  Include  overcoming 
the  foregoing  problems.  Space  does  not  permit  discussions  of  solutions  to 
these  problems  which  are  being  attacked  as  part  of  the  NSD  program. 

None  are  considered  Insurmountable  but  the  tentative  solutions  must  be 
examined  to  see  If  they  are  viable  and  cost-effective.  Applying  the 
principles  for  which  the  data  base  exists  Is  first  priority,  even  If  not 
done  as  neatly  as  desired  because  of  existing  problems.  Decision  processes 
related  to  ship  development  which  are  being  Implemented  annually  need 
help.  We  must  communicate  the  value  of  our  approach  to  management  and 
convince  them  to  take  advantage  of  It  as  soon  as  possible. 

There  are  two  primary  contributions  of  this  new  look  at  old 
data.  The  first  Is  centralizing  scattered  decision  making  Information  ? 
and  directly  associating  It  with  the  structured  operational  capabilities' 
expected  from  current  and  future  shlpborne  systems.  The  second  is  the 
capability  to  produce  custom  made  outputs  of  the  data  for  a wide  variety 
of  users  In  a short  time. 

The  proposal  of  new  Advanced  Systems  Concepts  to  be  developed 
through  RAD  is  Invited  by  reference  2 "for  entry  Into  the  Navy  development 
and  acquisition  selection  process".  A review  of  the  data  base  will 
Identify  needs  which  address  critical  Inadequate  operational  capabi- 
lities that  are  not  being  addressed  by  developments  In  progress.  In 
turn,  this  provides  the  opportunity  to  brlna  these  shortfalls  to  the 
attention  of  OPNAV.  The  current  procedure  * for  needs  Identification  Is 
a distributed  function  which  Is  centrally  coordinated  only  to  the  degree 
of  selecting  from  proffered  candidates.  The  new  look  provides  a basis 
for  comprehensively  Identifying  the  weaker  capabilities  or  short  falls 
from  each  mission  In  order  to  Induce  a search  for  proposals  to  relieve 
the  situation. 

These  advanced  system  concepts  can  be  examined  to  Identify 
technical  deficiencies  which  are  expected  to  prevent  or  degrade  an 
effective  system  development.  These  sub-needs  can  be  addressed  In  the 
exploratory  development  category  of  RAD  while  awaiting  acceptance  of  the 
advanced  development  system  accompanied  by  the  resources  necessary  for 
acquisition. 


1-1 


Independent  of  these  advanced  system  thrusts,  the  observation 
of  unfulfilled  needs  which  limit  effectiveness  of  current  shipborne 
systems  also  leads  to  critical  exploratory  development  efforts  as  well 
as  redirection  of  current  advanced  development  efforts.  The  continual 
accumulation  of  these  opportunities  for  Improvement  is  an  on-going 
process  identified  with  the  responsibilities  of  RAD  program  managers. 

The  new  look  provides  a better  record  for  top  management's  view  of  such 
candidates  for  funding  and  provides  a systematic  association  of  candidates 
with  the  mission  applications  Intended  both  to  fill  gaps  and  to  compete 
with  less  effective  options. 

The  cost  benefit  associated  with  the  identification  of  direction 
for  new  developments  must  include  the  Identification  of  time  constraints 
to  accommodate  the  formulation  of  new  ships  or  modernization  of  current 
ships.  The  current  process  of  ship  development  takes  advantage  of  RAD 
progress  only  if  it  has  occurred  by  the  time  ship  concept  design  commences. 
The  new  look  at  when  satisfaction  of  needs  would  be  most  appropriate 
will  contribute  to  cost  benefit  analyses.  These  analyses  will  affect 
both  direction  of  emphasis  in  resource  allocation  and  degree  of  advance 
of  individual  developments. 

The  recent  advent  of  force  sponsor  documents16  has  improved 
the  recording  of  expectations  from  RAD  associated  with  new  ship  develop- 
ments. In  addition  each  project  usually  has  some  ship  type  application 
mentioned  in  its  description.  The  new  look  acknowledges  these  data  and 
enhances  their  value  by  organizing  the  data  by  ship  type  and  by  associating 
milestone  plans  with  the  sequence  of  activities  necessary  for  a development 
to  become  Incorporated  into  a ship  system. 

This  new  look  is  partly  the  result  of,  but  more  importantly  is 
attuned  to  the  newQmanagement  thrusts  beinq  implemented  as  reguired  by 
di recti ves?LMENS,  ZERO-BASE  BUDGETING, 2U'MISSI0N  BUDGETING,  TECHNICAL 

STRATEGIES22)  intended  to  improve  the  knowledge  of  relevance  to  mission. 
Packaging  data  from  the  RBL  by  mission  area  (sets  of  SOC)  provides  the 
starting  point  for  evaluations:  (a)  demanded  by  ZBB  in  the  form  of 
decision  packages,  ( b ) suggested  for  organization  by  the  mission  budgeting 
report,  and  (c)  selected  as  the  structure  for  technical  strategies. 

3.  STATUS  OF  EFFORT 

Referring  to  the  original  hypothesis  In  the  Introduction 
concerning  the  ship  development  process,  for  each  portion  of  A - L there 
have  been  some  efforts  aimed  at  understanding  and  analyzing  the  sub- 
processes Involved.  There  are  many  descriptions  of  parts  of  the  overall 
ship  development  process  and  there  are  many  involved  organizational 
units  associated  by  charters,  instructions,  or  practices.  No  attempt 
has  been  made  to  consider  all  of  these  units,  but  as  a major  Influence 
on  the  process  is  recognized,  it  is  investigated. 


A visit  to  a cognizant  code  and  a copy  of  a pertinent  directive 
or  other  document  Introduces  a new  participant  to  the  system  and  Identifies 
the  "mechanism"  of  his  Involvement.  Each  new  participant  Is  considered 
a contributor  of  Input  and/or  a receiver  of  output.  His  participation 
Is  translated  Into  a language  compatible  with  the  languages  of  other 
participants  with  whom  he  may  not  have  direct  contact.  The  quality  and 
timing  of  Input/output  must  be  examined  to  recognize  opportunities  for 
Improvement. 

In  addition  to  the  status  of  the  NBL  data  discussed  In  B-2 
above,  Display  8 lists  for  each  element  A - L of  the  ship  acquisition 
hypothesis;  (a)  the  NAVSEA  "trustee",  and  (b)  the  "mechanisms"  which 
have  been  reviewed  for  their  potential  association  with  the  NBL  data 
bases,  the  status  of  which  are  discussed  below: 

a.  HYPOTHESIS  ELEMENTS  - A B f.nd  C 

MECHANISMS  - SECAS  and  APPROVED  CHARACTERISTICS 

SECAS17  represents  the  accepted  data  base  of  subsystem  options 
which  have  been  selected  for  active  fleet  units.  The  configurations  of 
these  ships  are  known  but  their  relative  performance  for  the  same  SOC 
need  to  be  examined.  We  are  acquiring  the  pertinent  portions  of  SECAS 
In  a form  compatible  with  the  objective  of  NSD,  that  is  to  establish  a 
baseline  of  Inventory  equipments  representing  future  subsystem  options 
if  no  RAD  projects  were  to  be  funded. 

Another  avenue  to  establishing  the  "starting  point"  for  sub- 
sequent sub-processes  Is  to6ass1milate  the  Information  available  In 
"approved  characteristics"^0  to  correlate  Installed  subsystems  with  the 
statements  which  suggest  why  they  were  selected. 

b.  HYPOTHESIS  ELEMENTS  - D and  E 

MECHANISMS  - Plans  and  Letters 

The  operational  needs  already  entered  In  the  NBL  represent  raw 
data  from  primarily  OPNAV  documents.  Supplementing  these  with  other 
needs,  which  are  known  by  participants  In  the  ship  development  process, 
and  from  privately  held  official  sources  (l.e.  existing  In  a set  of 
distributed  files,  rather  than  a centralllzed  file).  Is  a goal  In  the 
next  step  of  the  program.  Associated  with  this  data  collection  are  the 
current  efforts,  (1)  to  establish  a hierarchical  process  for  relating 
associated  needs,  (2)  to  combine  similar  statements  from  more  than  one 
source,  and  (3)  to  devise  an  Importance  rating  method  to  accommodate 
(1)  A (2). 

c.  HYPOTHESIS  ELEMENTS  - F,  G,  and  H 

MECHANISMS  - POM,  TLS,  and  PADS 

The  utility  of  the  NBL  In  the  decision-making  processes  which 
determine  (1)  the  funding  and  personnel  distribution  J among  items  and 
functions  under  NAVSEA  management,  and  (2)  the  selection  of  subsystem 
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options  (TLS,15  PADS27)  In  the  design  of  ships  will  be  determined  by  the 
progress  made  In  the  NSD  effort  and  by  the  awareness  and  appreciation  of 
how  it  can  be  used.  The  current  NBL  content  of  RAD  project  data  for 
shlpborne  subsystems  Is  complete  (except  for  NAVELEX  exploratory  development) 
through  FY  77  funded  projects  and  POM  80  proposed  projects.  A deficiency 
which  needs  early  attention  In  Improving  this  file  Is  the  lack  of  data 
depicting  the  next  lower  level  units  of  RAD  effort,  l.e.,  subproject  or 
task  level.  This  data  Is  needed  to  distinguish  more  clearly  the  multi- 
contributions that  projects  actually  address. 

d.  HYPOTHESIS  ELEMENTS  - I and  J 

MECHANISMS  - STEP  and  ASU 

The  replacement  policy  which  has-been  addressed  In  the  electronics 
field  by  Ship  Type  Electronics  Plan  (STEPr0  is  being  examined  to  realize 
the  Implications  of  an  earlier  mode  of  applying  similar  policy,  and  of 
extending  the  concept  to  fields  other  than  electronics. 

The  route  of  establishing  Approval  for  Service  Use  ( ASU  ) is 
also  being  examined  to  take  advantage  of  those  efforts  which  occur 
independently  of  ship  development,  but  which  could  contribute  to  the 
process  In  the  pre-acquisition  phase. 

e.  HYPOTHESIS  ELEMENTS  - K and  L 

MECHANISMS  - TLR,  MEL,  TLS  and  PMI 

The  current  processes  (TLR  /MEL/TLS  ) of  development  have 
much  to  gain  from  the  NSD  effort  and  are  prime  targets  for  improvement. 

Even  with  the  relatively  primitive  RBL  content  existing  today,  a draft 
TLR  (list  of  SOC)  can  be  used  to  generate  (1)  a first  Iteration  of 
(advanced)  MEL  options  for  the  TLS,  and  (2)  a mission  deficiency  (list 
of  needs)  observation  for  a second  iteration  TLR.  The  addition  of  SECAS 
data  to  the  baseline  will  improve  the  process. 

9 A 

The  "Proposed  Military  Improvement"  (PMr  ) concept  as  part  of 
the  Fleet  Modernization  Program  calls  for  early  identification  of 
potential  system  installation  plans.  The  NBL  milestone  data  implement 
and  extend  this  concept  to  earlier  but  less  definite  plans. 

Existing  data  bases  related  to  Hypothesis  elements  A thru  L 
are  being  brought  together  through  the  commonality  provided  by  structures 
such  as  the  "Ship  Work  Breakdown  Structure",q  (SWBS)  for  ship  subsystems 
and  the  Mission/Capability  (SOC)  structure  for  "Top  Level  Requirements" 
for  new  ships. 

Data  sources  include  people,  guidance  documents,  recurring 
reports,  and  existing  computerized  data  bases.  These  data  are  accumulated 
over  time,  annotated  with  useful  structures,  and  organized  in  planned 
work-sheet  displays  for  the  purpose  of  analyses. 


Customized  output  structured  for  a specific  analyst  provides  a 


unique  Input  for  planning.  Decisions  can  be  based  on  the  usual  Information 
available  at  the  time,  but  the  process  may  be  enhanced  by  the  comprehensive, 
orderly,  presentation  of  one  (or  more)  element! s)  of  the  Hypothesis. 

The  potential  spinoffs  of  the  Notional  Ship  Development  Program 
are  unlimited.  RAD  funds  and  efforts  can  be  managed  more  efficiently 
and  each  effort  can  be  justified  by  its  application  to  specific  operational 
needs.  The  business  of  acquiring  ships  for  the  Fleet  provides  the  only 
reason  for  the  existence  of  NAVSEA.  The  ships  acquired  should  be  those 
which  meet  the  operational  needs  of  the  Fleet  In  the  most  timely  and 
effective  manner.  The  NSD  program  can  aid  in  this  goal  and  should  be 
supported  at  all  levels. 
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Anti-air  Warfare  (AAW) 
Antisubmarine  Warfare  ( ASW ) 
Anti  surface  Ship  Warfare  (ASU) 
Strike  Warfare  ( STW" 

Amphibious  Warfare  ( AMW) 


3.  Supporting  Mission  Areas: 


. Mobility  (MOB) 

ommand  and  Control  and  Communications  (CCC) 


c.  Intelligence  (INT) 

d.  ElectroniF"Warfare  (ELW) 

e.  Logistics  (LOG) 

f.  Fleet  Support  Operations  (FSO) 

g.  Construction  (CM) 

h.  Noncombat  Operations  (NCO) 


1.  Guidelines.  All  fleet  units  as  well  as  combat  unit  components  of 
the  Naval  Reserve  are  designed  or  orgainzed  to  perform  one  or  more  of 
the  following  Naval  Warfare  Mission  Areas.  These  mission  areas  are 
divided  into  two  categories:  (1)  Fundamental  Mission  Areas  and  (2) 
Supporting  Mission  Areas. 


DISPLAY  4 

NAVAL  WARFARE  MISSION  AREAS 


2.  Fundamental  Mission  Areas: 


4.  Operational  Capability.  A subdivision  of  a mission  area  which  more 
specifically  delineates  appropriate  operational  functions.  The  selections 
have  been  made,  as  far  as  possible.  Independent  of  a platform  type. 


EXAMPLE:  ASW  9 - Engage  submarines  with  antisubmarine 
armament. 


5.  SUB-OPER.  CAPAB  (SOC) 


EXAMPLE:  ASW  9.6  - Attack  with  torpedoes. 
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DISPLAY  6 


Number 

05 

07 

10 

20 

30 

41 

42 

43 

44 

45 

46 

47 

48 
50 
59 

71 

72 

73 
75 

79 

80 


2-DIGIT 

SELECTIONS  FROM 
SHIP  WORK  BREAKDOWN  STRUCTURE 

Title 

(TOTAL)  SHIP  SYSTEM  PERFORMANCE 
GENERAL  REQUIREMENTS  (PROTECTION) 

HULL  STRUCTURE 
PROPULSION  PLANT 
ELECTRIC  PLANT 
COMMAND  AND  CONTROL  SYSTEMS 
NAVIGATION  SYSTEMS 
INTERIOR  COMMUNICATIONS 
EXTERIOR  COMMUNICATIONS 
SURVEILLANCE  SYSTEMS  (SURFACE) 

SURVEILLANCE  SYSTEMS  (UNDERSEA) 

COUNTERMEASURES 
FIRE  CONTROL  SYSTEMS 
AUXILIARY  SYSTEMS 
SPECIAL  PURPOSE  SYSTEMS  (OCEAN  & HUMAN  SUPPORT) 
GUNS 

MISSILES  AND  ROCKETS 

MINES 

TORPEDOES 

SPECIAL  PURPOSE  SYSTEMS  (WEAPON) 
INTEGRATION/ENGINEERING 
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DISPLAY  7 


FUNCTION/PERFORMANCE  AREAS 


VEHICLE,  GENERAL 
SHIPBORNE  SENSORS 
DEPLOYED  SENSORS 
SHIPBORNE  WEAPONS 
DEPLOYED  WEAPONS 
SHIP-BASED  AIRCRAFT 
MEDICAL/PERSONNEL 
LOGISTICS 


VULNERABILITY 

READINESS 

COMPONENT  TECHNOLOGY 
PLANNING  & MANGEMENT 


OFFENSIVE  CAPABILITY 
DEFENSIVE  CAPABILITY 
ELECTONIC  WARFARE 
ACOUSTIC  WARFARE 
COMBAT  SUPPORT 
NONCOMBAT  OPERATIONS 
AMPHIBIOUS  OPERATIONS 


CURRENT  SUB-PROCESSES 


